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1. (U//FOUO) Overview 

(U//FOUO) This specification exists to provide a common interface while preventing the use of other, 
more sensitive, execution specifications in persistence scenarios. It is not expected that this will be the 
only persistence interoperability mechanism implemented by the Sponsor, instead this specification 
provides a default. 

(U//FOUO) Persistence modules consist of a loader which utilizes a persistence technique and a payload 
to launch after a reboot or other execution ending event. Both pieces are exposed and vulnerable to 
hostile scrutiny and so must be simple, lack any definite attribution indicators, and easy to replace. 

(U//FOUO) Payload modules are Windows DLLs with at least one entry point defined, DllMain. 

(S//OC/NF) This specification is classified SECRET//ORCON/NOFORN to avoid hostile Foreign Intelligence 
Operations, Law Enforcement, Incident Response, Reverse Engineering, or any other investigation of 
captured tools or techniques resulting in attribution to the United States Government or the Central 
Intelligence Agency. Separate from that attribution the techniques discussed here are 
UNCLASSIFIED//FOR OFFICIAL USE ONLY. 

(U) The key words: MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, 
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119. 
In addition, the key words: SHOULD CONSIDER, REALLY SHOULD NOT, OUGHT TO, WOULD PROBABLY, 
MAY WISH TO, COULD, POSSIBLE, and MIGHT in this document are to be interpreted as described in RFC 
6919. 


2. (U//FOUO) Loading and Invocation 

1. (U//FOUO) The persistence loader gains execution through its persistence technique and causes 
the payload to be loaded into an appropriate process via LoadLibrary or equivalent 
technique. 

a. (U//FOUO) The loader should apply the default memory page permissions for a 

module's sections (i.e., as would be set by LoadLibrary). This prevents a single large 
chunk of PAGE_EXECUTE_READWRITE memory which could easily be found by memory 
forensics. 

2. (U//FOUO) From DllMain the payload spawns a new thread to execute its main code. 
DllMain otherwise behaves as per the MSDN documentation, to include return values. This is 
done to comply with the MSDN documentation of DllMain's execution environment. 

3. (U//FOUO) If possible the loader responds to DllMain's exit status as per the MSDN 
documentation. 

a. (U//FOUO) Loaders should collect the payload's exist status. Not all persistence 

techniques permit the loader to collect this exit status. If a particular technique does not 
make this feasible then the loader may ignore this return value and so leak it. 
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b. (U//FOUO) Loaders should zero the memory allocated to hold the payload prior to 
freeing it during unloading. Not all persistence techniques permit the loader to zero the 
previously occupied memory. If a particular technique does not make this feasible then 
the loader may skip zeroing the unloaded memory. 

4. (U//FOUO) If possible, the loader should release any open handles it has on the payload in order 
to permit the payload to self-delete or otherwise perform operations requiring an exclusive lock 
on its containing file. 

a. (U//FOUO) Payloads should be aware that they may not be resident as a plain DLL on 
disk and that consequently attempts to access their backing file may fail or return 
unexpected results. Payloads must handle this situation gracefully. If no graceful 
continuation of execution is possible, payloads may exit with an error condition. 


3. (U//FOUO) Arguments 

(U//FOUO) No arguments are passed between the loader and the payload. 


4. (U//FOUO) Structured Exception Handling 

(U//FOUO) Loaders will not provide fix ups to allow payloads to use Structured Exception Handling 
(SEH). If a payload wishes to use SEH it must perform the fix ups itself. 

5. (U//FOUO) Vectorized Exception Handling 

(U//FOUO) Loaders will not provide fix ups to allow payloads to use Vectorized Exception Handling 
(VEH). If a payload wishes to use VEH it must perform the fix ups itself. 


6. (U//FOUO) Uninstallation 

(U//FOUO) This specification explicitly does not define a mechanism for the payload to communicate to 
the loader that it should be removed. This is because persistence techniques vary so widely that a single 
standard could not reasonably accommodate all of the possible cases. The only requirement that this 
specification applies is that loaders and payloads must provide some mechanism for a user to stop or 
de-persist a given payload. 
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(U//FOUO) Appendix A: Version History 

(U//FOUO) Version 2: 

Renamed to Persisted DLL Specification for clarity 
Explicitly permitted loaders to skip zeroing unloaded payloads 
Removed argument passing support since it has not been necessary 
Clarification on release of file handles 
Clarification that payloads may not be simple files on disk 
(U//FOUO) Version 1: Initial publication 
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